Nebula 2/Nebula Two.iso/SourceCode/MiscKit1.7.1/MiscKitArchive.mbox/mbox/[e-mail]_Thu Feb 17 10:15:14 1994.msg

Internet Message Format | 1994-10-30 | 6KB

Return-Path: <[e-mail]>
Received: from post.demon.co.uk by darth.byu.edu (NX5.67d/NX3.0M)
    id AA00666; Thu, 17 Feb 94 10:10:49 -0700
Received: by post.demon.co.uk id ac15432; 17 Feb 94 12:28 GMT
Received: from steffi.demon.co.uk by post.demon.co.uk id aa13113;
          17 Feb 94 12:04 GMT
Received:  by steffi.demon.co.uk (NX5.67d/25-eef)
    id AA12377; Thu, 17 Feb 94 11:52:02 GMT
From: Robert Nicholson <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Breaking MiscKit into separate "levels" (WAS Re: MiscStringKit?)
To: [e-mail]
Date: Thu, 17 Feb 1994 11:52:00 +0000 (GMT)
Cc: [e-mail]
In-Reply-To: <[e-mail]> from "Don Yacktman" at Feb 17, 94 03:00:43 am
Cc: [e-mail]
X-Mailer: ELM [version 2.4 PL22]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 4757

Don Yacktman wrote:
> Well, I like this idea.  It might be a good way to go.  The question is then
> how we set up the libraries; do we make level 2 mean that the .a file has
> all of level 1 and level 0 in a single file, or do we make each level's
> .a file separate, and then to use the level 2 lib you have to link against
> the level 0 and level 1 lib?  Remember my whole point in creating the
> MiscKit initially was to stick in a bunch of objects I use a lot so that I
> could add one file -- the .a file -- in project builder and then I'm on my
> way.  It's makes things so much more comfy for the lazy.  :-)
>
> So I guess if disk space is no issue, the first option is the one the lazy
> person in me likes.  However, it's not much work to add a few libs to
> the project.  So since my disk space is at a premium, I think I'd in
> reality prefer the second option.  I don't think that this would be too
> terribly difficult to maintain, either.

I prefer multiple libraries.  ie. If I link with level 2 then I'm
expected to link with all levels above (and before it) it.   Take the
X11 libraries as an example.

X11
Xt
Xm

I don't like the notion where everything above and including level2 is in level 2's lib. MiscKit is still MiscKit then.

>
> Michael Pizolato's division is even finer-grained; I'm afraid that if
> we break things up too far that it will make the MiscKit too confusing
> to work with...but I think either scheme suggested would be pretty useful.
> How do people prefer to split things up?  We could do a hybrid:
>
> 0) C functions and macros only
> 1) depends on Object, too
> 2) depends on common classes
> 3) depends on appkit
> 4) adds palette support

Why is it necessary to have Object as a level?

Are classes in level 1 completely portable to over environments?

Why can't we just think of

C functions macros etc.
Object and Common Classes (ie. non-appkit)
Appkit
Palette

>
> Because of the way palettes are done, (4) might not be really necessary.

Michael, go into a bit more depth as to what you Palette support
library contains.

> And perhapd the IB methods should only be present as a category in the
> palette project, and not in the library itself anyway.  (cf. MiscString)  Does
> anybody use the IB methods to get info about an object other than from IB?
> If not, then maybe placing this in the palette projects would be best.

I'm currently using IB categories for each palette for things like
getIBImage etc etc, but I'd like to hear more about Michael's palette
support library.

>
> > The build process could produce either "misckit[012]" or just "misckit",
> > or both, depending on flags (that's not asking too much, is it?).
>
> I'd need a to learn a little more about Makefiles in order to do it this way,
> but it shouldn't be too horrid, I think.
>
> Then there's header organization...perhaps make four headers:
> <misckit/level0.h>, <misckit/level1.h>, <misckit/level2.h>, and
> <misckit/misckit.h>.  The last one just includes all of them; and
> the level[12].h would include the lower numbered headers.

Well the first hurdle is to form some meaniful names.  I don't want to
have to refer to a table whenever I see level[0-9].  However, the one
advantage of this naming scheme is that is it easy to identify
dependencies or at least possible dependencies. Perhaps we could use
macros to avoid that naming problems.

>
> > The relevance of this to Robert's comments it that String and
> > similar non-dependant classes could become part of a
> > 'lightweight' Level 0 class.  It also addresses the question
> > (in one of the newsgroups, I think) about what portions of
> > the MiscKit are applicable to non-NeXT platforms.
>
>
> I think that such a scheme would answer those questions, and
> provide useful objects for non-NeXT folks.  I think that would be
> a good thing.  And right now, the AppKit is pretty much intertwined
> throughout the MiscKit.
>
> Now, there is an important thing to note:  The NeXT and GNU Object
> classes _are_ slightly different; there are object methods in the GNU
> and in Cox's book that are not in NeXT's object class.  Things like
> deep/shallow copies, etc.  Perhaps we need a category for NeXT
> folk to extend things so that we are building on common ground.
> That's some food for thought...

A common object protocol is necessary. (Mr Pugh?)

>
> Oh, and suggested, we'd be better off using mnemonics than level
> numbers.  Any suggestions here?

Absolutely, but it's important to be able to identify dependicies by
name.
---
   "You know what's wrong with you?"              (Audrey Hepburn, Cary Grant)
       "No, what?"
   "Nothing"                                      (Charade, 1963)
                (ASCII for text only messages)